.NET SDK workloads overview spec #100
Conversation
richlander
changed the title
accepted/2020/workloads/workloads.md
Outdated
|
|
||
| ### SDK and workload versioning | ||
|
|
||
| Another benefit of the existing monolithic SDK is that the workloads it includes are known to be compatible with core SDK components, like the C# compiler, NuGet, MSBuild, and the SDK targets. Over time, we have developed the concept of an SDK version train. These are represented by SDK version hundreds bands like `3.1.100` and `3.1.200`. These version trains were created to align with Visual Studio versions, like `16.4` and `16.5`. We do this because those same core SDK components are shared between Visual Studio and the .NET SDK, and need to stay in alignment. In addition, new major versions of those components, possibly containing a new language version, can be delivered in these updates. We expect that workload manifests will need to be re-published for each SDK version train. That's an unfortunate requirement, however, the SDK version trains are a compatibility boundary that we would like to maintain. |
There was a problem hiding this comment.
We expect that workload manifests will need to be re-published for each SDK version train. That's an unfortunate requirement, however, the SDK version trains are a compatibility boundary that we would like to maintain.
I'm not entirely sure what this means, are you referring to the Nuget package that defines the component workload?
|
What happened to the Sdks concept?. Instead of introducing a new one, we should expand the capabilities of the Sdk concept. There are already Framework packs (older MetaPackages and TargetingPacks). We should use those to provide a modular SDK. For E.g.:
Let's take an example of Windows platform. It has WPF, WinForms, UAP, WinNT APIs
similarly for other platforms, you can have Common cross IDE support tools can also be provided via these packages as well in the form of a format You can also generate the |
Co-Authored-By: Kathleen Dollard <kdollard@microsoft.com> Co-Authored-By: Steve Kirbach <steven.kirbach@gmail.com>
This is a great question. We are continued to support and improve msbuild SDKs for third party scenarios. #104 deals with this topic. We are now using that mechanism for this feature because we want to avoid using NuGet for any aspect of the platform for reasons that are described in the doc. Make sense? |
|
Thanks for the feedback so far! I will merge this document in a few days if I don't hear any more feedback. We are still early in the release, so I am sure that there will be more changes and feedback after that. |
You can avoid NuGet since Sdk design is not limited to just NuGet Packages, they can be applied outside of it. |
accepted/2020/workloads/workloads.md
Outdated
| @@ -0,0 +1,97 @@ | |||
| # .NET Optional SDK Workloads | |||
|
|
|||
| In .NET 5, we will add support for iOS, Android, and Web assembly projects. Up until .NET 5.0, we’ve delivered all supported workloads via a monolithic SDK. As the supported workloads of the .NET SDK grow (and we want them to), it is no longer tenable to deliver an "all-in-one / one-size-fits-all" SDK distribution. There are many challenges to a large monolithic SDK, with product build time and distribution size being the most significant. Instead, all new workloads will be built and delivered separately from the SDK, and will be acquirable via your favorite installation tool (like the Visual Studio Installer, a Linux package manager, or the .NET CLI). In the fullness of time, we intend for all .NET workloads to follow this pattern, resulting in a very small and focused SDK. | |||
There was a problem hiding this comment.
| In .NET 5, we will add support for iOS, Android, and Web assembly projects. Up until .NET 5.0, we’ve delivered all supported workloads via a monolithic SDK. As the supported workloads of the .NET SDK grow (and we want them to), it is no longer tenable to deliver an "all-in-one / one-size-fits-all" SDK distribution. There are many challenges to a large monolithic SDK, with product build time and distribution size being the most significant. Instead, all new workloads will be built and delivered separately from the SDK, and will be acquirable via your favorite installation tool (like the Visual Studio Installer, a Linux package manager, or the .NET CLI). In the fullness of time, we intend for all .NET workloads to follow this pattern, resulting in a very small and focused SDK. | |
| In .NET 5, we will add support for iOS, Android, and Web assembly projects. Up until .NET 5, we’ve delivered all supported workloads via a monolithic SDK. As the supported workloads of the .NET SDK grow (and we want them to), it will no longer be tenable to deliver an "all-in-one / one-size-fits-all" SDK distribution. There are many challenges to a large monolithic SDK, with product build time and distribution size being the most significant. Instead, all new workloads will be built and delivered separately from the SDK, and will be acquirable via your favorite installation tool (like the Visual Studio Installer, a Linux package manager, or the .NET CLI). In the fullness of time, we intend for all .NET workloads to follow this pattern, resulting in a very small and focused SDK. |
accepted/2020/workloads/workloads.md
Outdated
| * The workload manifest is included as a required dependency for all variants of the workload (some packs might be optional). | ||
| * All referenced packs are included, matching the version specified in the workload manifest. | ||
|
|
||
| It should never be obvious to users that there is a compositional model at play. In particular, .NET tools should not produce errors because the workload manifest and required files are out of alignment in some way. |
There was a problem hiding this comment.
If they are "out of alignment in some way", what will tools do instead of error'ing? Is this comment saying that this is a valid situation that tools need to handle, and if so, what is the intended outcome?
There was a problem hiding this comment.
I took another run at that text.
Co-Authored-By: Stephen Toub <stoub@microsoft.com>
This document is an overview spec for a new concept -- workloads -- that remove the need to add new scenarios to the SDK (like Xamarin) in order to support them with .NET 5+. It will also enable us to remove workloads, like ASP.NET Core, and Windows Forms, from the SDK over time. The goal is to make the SDK super small and focused.
We will add more detailed specs on this topic in other PRs. See: